Skip to content

FINERACT-2457: Share transaction chronological validation incorrectly blocks new transactions based on rejected/reversed transactions#5403

Open
wkigenyi wants to merge 1 commit intoapache:developfrom
wkigenyi:ignore-reversed
Open

FINERACT-2457: Share transaction chronological validation incorrectly blocks new transactions based on rejected/reversed transactions#5403
wkigenyi wants to merge 1 commit intoapache:developfrom
wkigenyi:ignore-reversed

Conversation

@wkigenyi
Copy link
Contributor

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

  • Write the commit message as per our guidelines
  • Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
  • Create/update unit or integration tests for verifying the changes made.
  • Follow our coding conventions.
  • Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
  • This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

Your assigned reviewer(s) will follow our guidelines for code reviews.

Set<ShareAccountTransaction> transactions = account.getShareAccountTransactions();
for (ShareAccountTransaction transaction : transactions) {
if (!transaction.isChargeTransaction()) {
if (!transaction.isChargeTransaction() && transaction.isActive()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please tell me what is the current object for transaction rejected and reversed transaction, I think we can add unit tests for these case where when we perform transaction with reversed and rejected transaction it will work.

ShareAccountTransactionHelper.updateShareAccount(shareAccountId, updateShareAccountJsonString, requestSpec, responseSpec);

// Approve share Account
Map<String, Object> approveMap = new HashMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Share Account Approval Note logic seems to be duplicated in both tests, i think a helper function can be extracted especially this part

Map<String, Object> approveMap = new HashMap<>();
approveMap.put("note", "Share Account Approval Note");
approveMap.put("dateFormat", "dd MMMM yyyy");
approveMap.put("approvedDate", "01 March 2016");
approveMap.put("locale", "en");
String approve = new Gson().toJson(approveMap);
ShareAccountTransactionHelper.postCommand("approve", ...);

Map<String, Object> activateMap = new HashMap<>();
activateMap.put("dateFormat", "dd MMMM yyyy");
activateMap.put("activatedDate", "01 March 2016");
activateMap.put("locale", "en");
String activateJson = new Gson().toJson(activateMap);
ShareAccountTransactionHelper.postCommand("activate", ...);

for (Map<String, Object> transaction : transactions) {
Map<String, Object> transactionTypeMap = (Map<String, Object>) transaction.get("type");
List dateList = (List) transaction.get("purchasedDate");
Calendar cal = Calendar.getInstance();
cal.set(dateList.get(0), dateList.get(1) - 1, dateList.get(2));
Date date = cal.getTime();
String transactionType = (String) transactionTypeMap.get("code");
String transactionDate = simple.format(date);

if (transactionType.equals(...) && transactionDate.equals(...)) {
    ...
    break;
}

}

Map<String, List<Map<String, Object>>> rejectMap = new HashMap<>();
List<Map<String, Object>> list = new ArrayList<>();
Map<String, Object> idsMap = new HashMap<>();
idsMap.put("id", additionalSharesRequestId);
list.add(idsMap);
rejectMap.put("requestedShares", list);
String rejectJson = new Gson().toJson(rejectMap);
ShareAccountTransactionHelper.postCommand("rejectadditionalshares", ...);

Copy link
Contributor

@Aman-Mittal Aman-Mittal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There’s significant duplication across both tests: account setup, approve/activate flow, transaction lookup by date, rejection logic, and Calendar-based date extraction are repeated multiple times. I would Suggest extracting helpers for creating active share accounts, finding transactions by LocalDate, rejecting transactions, and approving/activating accounts. This would reduce test size substantially and improve readability and maintainability.

Set<ShareAccountTransaction> transactions = account.getShareAccountTransactions();
for (ShareAccountTransaction transaction : transactions) {
if (!transaction.isChargeTransaction()) {
if (!transaction.isChargeTransaction() && transaction.isActive() && !transaction.isPurchaseRejectedTransaction()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please filter the account.getShareAccountTransactions() result first and then iterate over them.

Set<ShareAccountTransaction> transactions = account.getShareAccountTransactions();
for (ShareAccountTransaction transaction : transactions) {
if (!transaction.isChargeTransaction()) {
if (!transaction.isChargeTransaction() && transaction.isActive() && !transaction.isPurchaseRejectedTransaction()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

… blocks new transactions based on rejected/reversed transactions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants